PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 3/USEnet 3.061

Text File | 1988-04-08 | 28.1 KB | 748 lines | [TEXT/ttxt]

29-Sep-87 09:37:02-PDT,29450;000000000001
Date: Fri 28 Aug 87 21:19:37-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V3 #61

Usenet Mac Digest     Friday, August 28, 1987        Volume 3 : Issue 61

Today's Topics:
     System enhancements
     Answer to 'snd ' question.
     animation packages, 3D graphics
     Lightspeed C question
     Re: Hypercard - How About New Mac Owner
     Which Is Better: DMCS or Concertware+?
     68851 PMMU for the II
     Coral/Franz Extended Common Lisp PRESS RELEASE
     Some notes on SubLaunching
     Zorak's Tomb
     Re: Mac C Compilers, Benchmarks, Stupidity
     Can you suggest a PowerPoint Patch?
     Tape Drives?
     Re: Astrology Software?
     QMS PS Printers Query
     Re: 68851 PMMU for the II
     Need info on DASCH RAMdisk
     Backgrounding in MultiFinder
     TextEdit and Arrow keys

----------------------------------------------------------------------

From: [e-mail] (D. Ranson CNET)
Subject: System enhancements
Date: 20 Aug 87 06:29:28 GMT


Yet another (several others!) suggestion for Mac system enhancements:

-  SFGetFolder and SFPutFolder calls in Standard File

- Mini-icons (SICNs) in menus

- Window re-arranging traps (tiling, ordering, stacking and such). Doing
it the ToolBox way is desperately slow because of region calculations
that should be turned off until all windows are in place.

- And PLEASE APPLE, we need a version 2 _SysEnvirons trap! New
information needed includes availability of new Menu Mgr, flags for
Switcher and Multi- Finder, and probably more.

   Thanks.
   Daniel Ranson
   ...!seismo!mcvax!inria!{crcge1 or cnetlu}!ranson


------------------------------

From: [e-mail] (Richard Siegel)
Subject: Answer to 'snd ' question.
Date: 20 Aug 87 13:23:59 GMT


I received an  answer to my question about the 'snd ' resources used in
HyperCard from Byron Han, of Apple Computer. Herewith is his reply to my
question (he requested that I post it for him):

-----------

there are currently two types of "snd " resources.  type 1 is the kind
that will play in the sound CDEV in the control panel.

type 2 is the Bill Atkinson version which will only play in Hypercard
and/or the MiniServant.

/*--------------------------------------------------------------------------*/
/*  NOTE: I am _NOT_ an Apple representative.  All statements and opinions  */
/* are my own and are _not_ to be construed as any official Apple position. */
/* Byron B. Han                 UUCP: {sun,voder,nsc,mtxinu,dual}!apple!han */
/* Apple Computer, Inc.        CSNET: [e-mail]                       */
/* 20525 Mariani Ave MS 27Y    GENIE: BYRONHAN         CSERVE: 72167,1664   */
/* Cupertino, CA 95014        ATTNet: 408-973-6450  APPLELINK: HAN1         */
/*--------------------------------------------------------------------------*/

------------

My next question is: is there any way to play the type 2 'snd '
resource?

The "Sound Off II" INIT file has no problem playing either type, so it
must be possible.... Also, how does the Sound CDEV set the system beep
to be a given 'snd ' resource?

        --Rich

R-Squared Development Systems
134 Horseshoe Drive
Williamsburg, Virginia 23185
[phone] [After 6pm eastern time only]

Arpanet: [e-mail]
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u

Disclaimer? I don't even KNOW 'er!

"Do you wanna be a cop or a lost cause?"
    -- Sean Connery, in "The Untouchables"

------------------------------

From: [e-mail] (Bill Roberts)
Subject: animation packages, 3D graphics
Date: 20 Aug 87 15:32:05 GMT
Organization: High Altitude Obs./NCAR, Boulder CO

I was wondering if anyone might be able to make some objective comments
about some Mac software.  For instance,

    1) How does Beck-Tech's "MacMovies" compare to Haden's "VideoWorks"?
    2) How does "Easy 3D" compare to "Mac 3D"?


Thanks in advance for any info pertaining to these questions and
packages?

--Bill

UUCP: {hplabs, seismo, nbires, noao}!hao!bill
CSNET: [e-mail]
ARPA: [e-mail]
INTERNET: [e-mail]

------------------------------

From: [e-mail] (Robert Dorsett)
Subject: Lightspeed C question
Date: 19 Aug 87 23:26:28 GMT
Organization: Austin UNIX Users Group, Austin, Tx.

Another question I had on Lightspeed C is its capability (if any) to
permit the user to write program text in all lower-case.  I find mixed
case to be a royal pain in C, in general, and prefer to write in lower
case.


--
Robert Dorsett                          {allegra,seismo}!sally!ngp!walt!mentat
University of Texas at Austin           {allegra,seismo}!sally!ngp!mentat
                                        [e-mail]

------------------------------

From: [e-mail]
Subject: Re: Hypercard - How About New Mac Owner
Date: 19 Aug 87 14:05:00 GMT


Why is Apple charging the $50 in the first place?  I can't imagine they
are going to make lots of money from it.  It's far more than
distribution cost.  Is it to give dealerships a profit on the thing?  Or
is it to give an incentive to people to buy macs (they're getting
something for free)? It sure isn't good PR--rightly or wrongly, most of
us have come to expect to get operating system upgrades from Apple for
free, and having to pay for this one hurts a little.

And will these things be posted on the BBS?  If not, what happens when
Multifinder 1.1 comes out?  Another $50?
----
Steve Dorner, U of Illinois Computing Services Office
Internet: [e-mail]  UUCP: {ihnp4,seismo}!uiucuxc!dorner
IfUMust:  [phone]

------------------------------

From: [e-mail] (H. Moskovitz)
Subject: Which Is Better: DMCS or Concertware+?
Date: 20 Aug 87 20:03:57 GMT
Organization: The Second Door on the Right

I was playing around with a friend's copy of Deluxe music Construction
set. I liked it except for the problem that it an old version and does
not work properly with the latest version of OS on the SE (4.1/5.5), so
I must run it from the floppy as the boot disk which makes it slooooow.
Also, it does not like the HFS filesystem and does not find stuff inside
folders.

My question is: are these problems resolved in the new + improved DMCS?
What NEW features are in it? How does Concertware+ Midi compare to DMCS?
Since they are both in the same ballpark pricerange, which is more of a
bang for the buck?

                Thanks (in advance). --
-----------------------------------------------------------
        Howard Moskovitz
    AT&T Bell Labs @ Liberty Corner, NJ
        ihnp4!io!howard


------------------------------

From: [e-mail] (Lawrence Dziegielewski)
Subject: 68851 PMMU for the II
Date: 20 Aug 87 21:33:15 GMT
Organization: E.I. DuPont Co. Engineering Physics Lab

I have recently acquired an XC68851RC16 PMMU for my Mac II.  I have not
received my AU/X yet,  so I have put off installing it.  My question:
will installing the PMMU have any effect on the performance of the II
under the Finder,  or maybe the MulitFinder?  My memory configuration is
5 MB.

Also,   where does the PMMU install on the motherboard.  Thanks in
advance for the help.

--
    Lawrence A. Dziegielewski    |    E.I. Dupont Co.
    ...{dgis!psuvax1}!eplrx7!lad    |    Engineering Physics Lab
    Cash-We-Serve 76127,104        |    Wilmington, Delaware 19891
    MABELL:  [phone]        |    Mail Stop: E357-318


------------------------------

From: [e-mail] (bill coderre)
Subject: Coral/Franz Extended Common Lisp PRESS RELEASE
Date: 20 Aug 87 23:27:56 GMT
Organization: Apple Computer, Inc., Cupertino, USA

Alright, it's time to post a press release for Coral Extended Common
Lisp (Allegro). {Note: "ECL" is sometimes used elsewhere to refer to
ExperCommonLisp, an entirely unrelated product.}

First, be aware that Coral developed the Mac kernel mentioned here, to
which will be added the Franz ECL extensions. ECL is being renamed
"Allegro".

Second, be aware that I was a tester of the product. Now I am a user. I
have never been paid by them, nor do I have any stake in the product. I
am only working for Apple for the summer, do not confuse my return
address with any official endorsement from Apple.

Anyway, this is a press release I made up, not them. I've brought it in
line with their releases, but mine has considerably more detail. Any
errors in specification are probably my fault.

             Allegro Common Lisp
                Coral Software
                  POBox 307
              Cambridge MA 02142
                [phone]
         Outside Massachusetts: [phone]

        "A programming environment for the CDR of us."

Allegro Common Lisp for the Macintosh line of personal computers is now
shipping for $399.95, INTRODUCTORY PRICE. Allegro is not copy protected
and includes a money-back guarantee.

Allegro CL contains the FULL Common Lisp as specified in *Common Lisp:
the Language* by Guy Steele. Everything mentioned in the book is
implemented.

Allegro CL will run off floppy disks and will run in a 1MB MacPlus. At
least 2MB and a hard disk are recommended. (Related files currently
clock in at 1.6MByte.)

Allegro will run approximately 5 times faster on a 16MHz 68020 machine,
for example a Mac II or a third-party processor upgrade.

When a 68881 coprocessor is present, Allegro will call it directly.

Alegro also supports "leading brand" large screen monitors.

But that's just the start.....

Allegro uses a fast, incremental native code compiler, and is truly
tail-recursive. File compilation is provided now, but standalone
applications are "coming soon."

There is also a low-level interface to allow acess to any Mac OS or
toolbox trap. It provides all the necessary glue to build stack records,
pascal data types, registers, etc. In addition, a Lisp Assembly-language
Programming (LAP) package is "coming soon", and a foreign function
interface will be available (to MPW C, Pascal, and Assembler).

There is an object-oriented programming system incorporated: a version
of ObjectLisp, which was developed by Gary Drescher. Despite being easy
to learn and use, ObjectLisp provides powerful multiple inheritance
features. CLOS (the official Common Lisp Object System) will be "coming
soon." (The spec isn't done yet, after all!) Flavors is "coming soon."

There is also object oriented support for windows. Your window subclass
can fully build on the pre-existing window class. Windows are also a
subclass of streams, so all the CL stream commands will work. Many
quickdraw primitives are provided in high-level form, too, including
operations on regions and pictures.

Menu items, menus, and menubars are provided as objects. Support is
provided so that when a user selects a menu item, an associated function
is called. Menus have all the style and features of regular Macintosh
menus, except for icons and hierarchical menus. Users may make their own
menus and change the menubar, menus, and menu items in any way.

Dialogs (both modal and modeless) are provided as high-level objects.
Dialog items, similar to menu items, can be subclassed, and call a
function when triggered. Normal dialog items are supported, as well as
one-dimensional scrollable lists, and 2-D scrollable tables.

Simple event-handling is provided. It is easy to write Allegro CL code
that works similarly to a "standard" Macintosh event-driven program.

A pathname subsystem, which extends and customises CLtL's File System
Interface to the Macintosh environment, is provided.

Built-in is FRED the Editor, an editor which provides many commands from
EMACS, as well as the standard Macintosh editing modes, extended for a
Lisp environment. FRED can be used in your programs, to edit your own
buffers. Of course, full documentation is provided for extending and
modifying FRED's behavior. FRED has a key bindings window that shows
current bindings.

A stack backtrace window is provided for debugging. It also allows the
inspection of call frames, and the temporary binding of call values,
modification of values, evaluation of functions in the call-frame
environment, etc.

A visual stepper is provided, for watching functions execute, and has
similar functionality to the backtrace window.

An inspector with features to examine any CL or Mac datatype included.
The user need merely click on a field or value to inspect it further.

Meta-point is provided, and works across multiple source files.
Edit-definition is provided. An Apropos window is provided.

A kill ring is maintained, has a window interface, and hooks into the
Macintosh Clipboard.

Windows are provided for user preferences for printing and environment
variables. A windows menu is provided for selecting any window.

A "List of Definitions" buffer is provided, with buttons for buffer and
alphabetical order. It also allows jumping directly to a function.

Also "Coming Soon": Macintosh User Interface Designer Stack Groups
Common Windows


------------------------------

From: [e-mail] (Mac DLab)
Subject: Some notes on SubLaunching
Date: 20 Aug 87 17:11:09 GMT
Organization: Reed College, Portland OR

I have spent some time recently with sublaunching, and have a few
comments and a question which may be of interest to other sublaunchers.


Option-Sublaunch

After using my sublaunch implementation for a couple of weeks, I noticed
an undocumented system "feature."  Holding the option key down during a
sublaunch nullifies the sub-launch in the sense that quitting the
sublaunched application returns you to the Finder, not the launcher.
Holding the option key down while quitting a sublaunched application
also returns you to the Finder.

And, in fact, if you have several sublaunches stacked up and option-key
abort to the Finder, opening up another application from the desk-top
puts you back into the launch chain.  I.e. when you quit the application
you clicked on from the finder, control returns to the last application
that did a sublaunch.

Although I can see some utility to this, it can really cause trouble for
applications that do sublaunches, especially when the developer doesn't
know about the option-key trick.  If, for example, you leave ERIK
wdrefnums allocated (expecting them to still be good when your sublaunch
returns), you get screwed by the Finder since it dumps all of the
ERIK's.

I might also note the option-key trick is a drag when you are trying to
sublaunch applications that assign special meaning to being booted with
the option held down (e.g. Font/DA Mover).

I sent a letter to tech support asking why this "feature" was not
documented, and they gave me the uncharacteristically annoying reply
that (and I am paraphrasing here) 'we aren't documenting
option-sublaunch since we're not sure if we're going to leave it in the
next system.' !!?? I don't know about you, but this strikes me as a
rather dangerous attitude toward documentation in general.


Returning from a Sublaunch

When I return from a sublaunch, I want to know about it:  my program
needs to set up the same environment that the user left at the time of
the sublaunch.  If booted from the Finder, I obviously want to just
start up in a normal configuration.

My first thought was, "Well, how does MPW do it?"  Unfortunately, the
answer is that MPW uses low-memory globals of some sort to store
information. Hey, I'm not that desperate!

Use a file or resource to save the information?  That's no good, since
if the sublaunched application crashes, the next time my application is
booted from the Finder, the file will still be there and I will think I
am returning from a sublaunch.

It turns out that a nice solution is to save a system heap handle in a
resource each time you sublaunch (either in the application resfile, or
some other resfile that the application can always get to). In the
handle, you put a string (say, "sublaunch in progress"). Whenever your
application boots:

1) Get the handle from the resource. 2) Make sure it is non-zero (see
step 6). 3) Make sure that it is a valid handle. 4) See if it points to
the "sublaunch in progress" string. 5) If so, zero the string in the
system heap, then dispose of the handle. 6) Put a Nil handle in your
resource.

You can of course keep whatever sublaunch information you want in the
handle also (filenames, wdrefs or dirids, etc.) that can be used on
return from the sublaunch.

There is one catch -- what happens if you sublaunch yourself, or if a
sublauchee sublaunches you?  Well, nothing bad happens.  Your
application will start up thinking it has returned from a sublaunch,
with no harm done.  However, when you return to the original launcher,
the handle will be cleared and it will think it has booted from the
finder.

Question:

What I would like to see is an infinite number of sublaunches with
proper return from each one -- I haven't figured out a bullet-proof
method for doing this yet.  Tech Support is silent on the possibility of
examining whatever structure keeps track of the sublaunch history -- I'm
sure this could be discovered with a little bit of debugger work, but
would be a suicidal path in terms of being compatible with future
systems. Any suggestions?


Scott Gillespie
Reed College
{decvax, and a host of others}tetronix!reed!maclab

------------------------------

From: [e-mail] (Michael S. Temkin)
Subject: Zorak's Tomb
Date: 18 Aug 87 20:35:06 GMT
Organization: Calif State Univ, Northridge, Computer Science Dept

Sorry if I mispelled the name.

I was looking at this game at B. Dalton's Software Etc. and was thinking
of purchasing it.  The description sounds decent, but it also leaves
room for a big let-down.  If anyone has any thing to say (good, bad,
censored, etc.) please let me know.

            Thanks in adv.
                Mike Temkin

BTW: Software Etc. (at the Northridge mall in CA) seems to have a fairly
good selection, and they will let you demo programs.

--
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Michael Temkin        {inhp4,hplabs,psivax,ttidca}!csun!cs1!mst "Oh, I was
supposed to push that button first?!" "Is there anybody out
there?...Hello?..."
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.


------------------------------

From: [e-mail] (Joel West)
Subject: Re: Mac C Compilers, Benchmarks, Stupidity
Date: 21 Aug 87 03:35:03 GMT
Organization: Palomar Software, Inc., Vista, CA

Incidentally, I checked with Byte, and they said they'd gotten more
complaints on that one article than anything else ever, and that
complaint had come from both the Mac and PC sides. Expect a new set of
benchmarks in a future issue, although I have no idea of how they'll go
about it differently this time.


------------------------------

From: [e-mail] (mike parker)
Subject: Can you suggest a PowerPoint Patch?
Date: 21 Aug 87 06:03:32 GMT


I really enjoy using Powerpoint, except for one little annoyance...

Indentation is controled by the "left" anr "right" commands, which have
command key equivalents of "command-l" and command-r".  For some reason
this comes very unnaturally to me and I have to stop and think ehrther I
want r or l each time.  It seemd to me that such a thing should be very
reseditable.  I would like to change them to "command-<" and
"command->", or should I say "command-shift-,: and "command-shift-.".

So, how easy is the change? What do I do?

Thank-you

Mike

--
 UUCP: {hplabs,amdcad,ihnp4,allegra}!amd!mikep
 ARPA: amdcad!amd![e-mail]
 USPS: Mike Parker, AMD, P.O. Box 3843, M.S. 6, Sunnyvale, Ca. 94088
 AT&T: 408-982-6772


------------------------------

From: [e-mail] (mike parker)
Subject: Tape Drives?
Date: 21 Aug 87 06:11:44 GMT

Sorry for all of the typo's in the PowerPoint posting, oh well, another
question.  We're getting to have a reasonable number of macs here, and
I'm tired of backing up to disk.  If I get one tape drive can I back up
all macs on the appletalk, or do I have to move the drive from mac to
mac?  It seems obvious, but the drives do come with backup software
don't they.

What's your favorite tape drive?  Why?  How good is the interface for
restoring a single file?  It seems like the backup software ought to let
me select files from an SFGetFile style dialog box, rather than make me
go through all disks one file at a time.

Mike

--
 UUCP: {hplabs,amdcad,ihnp4,allegra}!amd!mikep
 ARPA: amdcad!amd![e-mail]
 USPS: Mike Parker, AMD, P.O. Box 3843, M.S. 6, Sunnyvale, Ca. 94088
 AT&T: 408-982-6772


------------------------------

From: [e-mail] (sunny at Infinity Software)
Subject: Re: Astrology Software?
Date: 21 Aug 87 07:33:21 GMT
Organization: Infinity Software, Everyville, CA

Graphic Astrology
Time Cycles Research
27 Dimmock Road
Waterford, Connecticut

------------------------------

From: [e-mail] (Maurice Weitman)
Subject: QMS PS Printers Query
Date: 5 Aug 87 05:28:40 GMT
Organization: The Maurizio T. Butthead Computing Companies

Well, it's a couple of months after Macworld's rave review of the QMS
PS-800 Plus printer, and I'm considering buying one.  Has any MacNetter
had any experience with them?

Thanks in Berkeley.  (Close to Advance.)
--
Maurice Weitman           ..!{dual,hplabs,lll-crg,ptsfa,glacier}!well!mo
 | <- this is not a pipe   POBox 10019 Berkeley, CA  94709  [phone]
Quote:  "What a revoltin' development this is." Maurizio T. Butthead, 1986
Disclaimer:  Any errors in spelling, tact or fact are transmission errors.

------------------------------

From: [e-mail] (Joel West)
Subject: Re: 68851 PMMU for the II
Date: 21 Aug 87 14:27:18 GMT
Organization: Palomar Software, Inc., Vista, CA

Go to Radio Shack and buy their chip puller (it looks like a pair of ice
tongs or large tweezers).

Near the front of the motherboard is a chip labeled (C) Apple '86, one
of the big square chips.  The others are labelled Motorola and are
recognizable.  Pull the Apple HMMU out and place the 68851 in the same
orientation.

The Mac OS runs just fine.  I haven't done any speed benchmarks to
establish whether it's any slower, but it's certainly not noticeable.


------------------------------

From: [e-mail] (SHR1-3/O11..DTN 237-3413)
Subject: Need info on DASCH RAMdisk
Date: 21 Aug 87 17:32:45 GMT
Organization: Digital Equipment Corporation


I'd like some information from people that have used or are using the
DASCH RAMdisk.

1. Does anyone have Disk Timer results for it?
2. Why did you buy/use it?  What applications do you feel need that
   high performance from the disk?
3. Are you/Were you happy with it?  What did you like about it?  What
   didn't you like about it?

Please mail me responses directly.  I'll summarize for the net.  Thanks.

Charlie Cassidy        Digital Equipment Corp.
                       Electronic Storage Development

[e-mail] -or-
{decvax, ucbvax, allegra or your favorite path to}!decwrl!memory!cassidy

USnail:    Digital Equipment Corp        Phone: [phone]
        333 South St.   SHR1-3/O11
        Shrewsbury, MA  01545

------------------------------

From: [e-mail] (D. Ranson CNET)
Subject: Backgrounding in MultiFinder
Date: 21 Aug 87 14:33:46 GMT

Can a background task under MultiFinder make itself foreground? e.g. by
posting a mouseDown event in its window? I'm thinking about things like
a screen blanker that would wait for idleness in the background, then
show a black window.

The BIX article was unclear about limitations of background tasks. Is
file I/O really OK? How about creating or selecting a window?

    Daniel Ranson
    ...!seismo!mcvax!inria!{crcge1 or cnetlu}!ranson


------------------------------

From: [e-mail] (Brian H. Powell)
Subject: TextEdit and Arrow keys
Date: 21 Aug 87 19:19:20 GMT
Organization: U. Texas CS Dept., Austin, Texas


     I sent a letter to Apple concerning several topics, one of which
was a request for any information on how to get the anchor point info
out of TextEdit.  I got a rather unusual reply, which I think needs some
discussion.

>Brian,
>     As a general rule, your application should not take any explicit action
>when special keys are pressed.  Instead, your application should just pass the
>key on to TextEdit.  This way, when we develop new keyboards (or alternate
>input devices), we will also update TextEdit to handle the new keys.
>     For example, TextEdit now handles the arrow keys correctly.  If you
>handle the arrow keys yourself, not only are you relying on the character or
>key codes of the arrow keys remaining unchanged, but you will also be changing
>the functionality of TextEdit with which users are already familiar.

     It's news to me that TextEdit now handles the arrow keys correctly.
 It handles left and right arrow correctly.  It does not handle up and
down arrow correctly, and it doesn't handle the arrows with any of the
modifier keys pressed.  (If we neglect the option-key, which has
application-specified semantics, there are 16 cases to handle (four
arrows * no modifiers, shift, cmd, and cmd-shift).  Apple got two of
them right in TextEdit.)  Be sure to read the User Interface chapter of
Inside Mac, Volume IV, to learn the proper actions to be taken by the
arrow keys.  If you think about it, TextEdit isn't powerful enough to
implement those guidelines; they'd need two or three more fields in the
TERecord to do it right.
     And then there's the fact that TE on a 128K Mac (and the Lisa)
doesn't handle arrows at all, but I don't think Apple really cares about
that.
     If Apple changes the character codes returned by the event manager
for the arrow keys, my program will not be the only program to break.
What about all those programs that don't use TextEdit and still try to
use the arrow keys.  Several such programs come to mind:  MS-Word,
MacWrite, spreadsheets, programming language editors, ...  I'm not
saying that Apple should set the character codes in stone, but get real:
 a lot of programs are going to break, and I don't mind if mine is one
of them.  I'll take that chance.
     As for the key-codes.  I really doubt they'll stay the same.  But
somehow, I've got to implement shift-arrow and cmd-shift-arrow, and the
64K and 128K ROMs (or is it the keyboard 8021 ROMs?) return certain
mathematical symbols (consult your numeric keypad) for those keydowns.
(Actually, the Mac-Plus works right for cmd-shift-arrow, but not
shift-arrow.  The 64K Rom macs don't get either right.)  Sooo, my
program checks the ROM version number, and if it finds a 64K or 128K
ROM, it consults the key-code, otherwise it takes the event manager's
word that the character-code is right.
     As for users being familiar with TextEdit, that's not the point.
The point, last time I checked, was to implement the Mac User Interface
guidelines.  (Or did the U.S.S.R. take over North America?  I didn't get
to see the news last night.)

     Let's continue with the letter:

>     When shift-clicking to extend a selection range, TextEdit considers the
>selStart point to be the "anchor".  If the user shift-clicks within the
>current selection, the selection is reduced to be from selStart to the click
>location.  If the user shift-clicks past the end of the range, then the new
>selection is also selStart to the click location.
>     Only if the user shift-clicks before the start of the selection are
>things different.  Then the new selection range extends from the click
>location to selEnd.
>
>                I hope this helps,
>
>                Chris Derossi
>                Developer Tech Support Technoid

     I disagree with this behavior, but I live with it.  Shift-Clicks
before the anchor point should select from the click to the anchor
point. Shift-Clicks after the anchor point should select from the anchor
point to the click.  Remember, IM-IV, p. IV-5 says "Once selection
begins, the anchor point cannot be moved except by beginning a new
selection."
     To fix this, you have to do some nastiness inside your clik_loop.
(You are using your own clik_loop, aren't you?  Surely you're not using
the ROM's.) I don't think it would be worth it to change this behavior.
(Actually, I may try it, just to see if it works.)

     I've got 8 pages of C code that handles keyboard input.  Most of it
addresses, you guessed it, arrow keys.  It's a pain to implement them in
TextEdit, but it can be done.  I may put together a medium-sized posting
which discusses some of the finer points.

Brian H. Powell
        UUCP:    {ihnp4,seismo,ctvax}!ut-sally!brian
        ARPA:    [e-mail]

   _Work_                     _Not Work_
  Department of Computer Sciences        P.O. Box 5899
  Taylor Hall 2.124                Austin, TX 78763-5899
  The University of Texas at Austin        [phone]
  Austin, TX 78712-1188
  [phone]

------------------------------

End of Usenet Mac Digest
************************
-------
-------